home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 666 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.8 KB
  1. Date: Sat, 2 Jul 94 00:32 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: Available Keyboard Keys
  5. Precedence: bulk
  6.  
  7. MULTI-PURPOSE KEYS :
  8.  
  9.   The idea of which keys are available currently reads as thus :
  10.  
  11.   "Any key may use control.  Any key that is single-purpose, ie only one
  12. symbol on the key, may use shift-control."
  13.  
  14.   T.Miller simply wants shifted and unshifted to be the same for single-
  15. purpose keys, which seems fine with the above statement.
  16.  
  17.   NEITHER IDEA WILL WORK!!
  18.  
  19.   Think about it.  Under the guidelines above, I can define ^< and ^> to
  20. be different functions.  On some keyboards, these will be the same key!
  21. If you want to use multi-purpose keys (those that have more than one
  22. symbol on them), then the use of shift must be assumed to be implicit
  23. in the symbol itself.  Otherwise, no multi-purpose keys!  Numbers may
  24. be used as the only exception, as you can have a number and a shift
  25. control number on all keyboards.  Likewise + and = may be the same or
  26. different keys!!
  27.  
  28.   In any case only symbols in the ascii set from 33-126 may be used, and
  29. no special european or Hebrew keys, even if these are easily accessable on
  30. other keyboards.
  31.  
  32.   If the group decided that we need multi-purpose keys, and the use of
  33. shift is implicit, then why can't the use of shift be implicit in alpha
  34. keys too?    So ^A is shift-control-A and ^a is just control-A?  This
  35. makes the idea of an implicit shift global throughout all key definitions
  36. making the non-alpha implicit keys more understandable (you will know a
  37. app uses implicit shift in the keys as soon as you see lower-case letters
  38. in the menus).   This also saved a symbol in the menus.
  39.  
  40.   I think I'm making a pretty strong argument here for the use of implicit
  41. shift throughout the key definitions and have shown that we MUST use 
  42. implicit shift if we use multi-purpose keys at all.
  43.  
  44.  
  45. GEM-LIST MULTISTANDARD :
  46.  
  47.   At first glance the GEM-List standards seem quite simple.  If the
  48. programmer is lazy, he only needs to support level #1 of the standard and
  49. can hard-code the GEM-List keyboard short-cuts without use the App-defs
  50. file.   Programmers that want the most flexibility support the App-defs
  51. file, and if this is not found, is damaged, or does not contain the 
  52. proper function, he then uses whatever is defined in the level #1 standard.
  53.  
  54.   Now look deeper into the problem.  Say, 50% or programmers support the
  55. App-defs file and 50% of the apps only use the level #1 standard.  A user
  56. could then have most of his apps configurable, and he can change those keys,
  57. but if he changes from the defaults, the other half of his applications
  58. will not use the same keyboard short-cuts!!  This is not _A_ standard as
  59. it creates TWO incompatible standards.  The only way the standards are
  60. compatible is if the App-defs file is never changed, and this makes level 2
  61. useless!
  62.  
  63.   Therefore, we CANNOT have 2 standards.  The biggest problem with standards
  64. is that there are so many to choose from.  So, we MUST vote on either level
  65. #1 (short-cuts hard-coded) or level #2 (short-cuts defined by file).  I think
  66. the list pretty much shows how divided we are on what the short-cuts should
  67. be.  I think we should stick close to the Atari, Apple, and NeXT guidelines.
  68. Ofir thinks we should stick close to the German standard.  The ONLY way to
  69. compromise, is to support the App-defs.sys file.  If we have to, we can
  70. create 2 sample App-defs.sys files, one following the Atari/NeXT/Apple
  71. guidlines (ANA?) and the other following the German Profibuch <sp?> guide.
  72.  
  73.   Again, the file allows all apps to have the SAME short-cuts.  It is 
  74. therefore a standard.  A 2-way standard is NOT a standard (the problem with
  75. standards is that there are so many to choose from!).  And if we choose to
  76. hard-code the keys, then someone will be unhappy (namely me!  ^U for close
  77. window?  What is underline again?)
  78.  
  79.  
  80. CONCLUSION
  81.  
  82.   The current handling of multi-purpose keys is inadequate and impossible to
  83. implement.  The current bi-level standard is NOT a standard and actually
  84. makes the GEM-List a counter-active force, just adding more confusion to the
  85. masses.  I have given my reasons for supporting an implicit shift in the
  86. symbol used for keys and this is easily checked by following the generated
  87. ASCII codes and makes implicit shift a global and less confusing idea.  
  88. Please give counter-argument to this idea.   Second, I have shown why I think
  89. APP-DEFS.SYS is the only way to continue, and I do NOT want to hear any
  90. counter-arguments.  Anyone that thinks that we can create a standard that
  91. is SO good that no one will want to change is not reading the list!  I want
  92. window close to follow the guidelines of 3 major companies.  Ofir wants to
  93. follow a standard that was created by the German ATARI community that has
  94. never been accepted by ATARI.  You can't please both of us.
  95.  
  96. Thank You for reading!
  97.  
  98.  
  99.  
  100.